V04 Meilensteine

Änderungen

• 2026-11-04 Nach Meilensteinen neu strukturiert

Teamprojekt Softwareentwicklung

(SEP)

Erinnerung: Spezifikationsdokument

• Vorabgabe: 2026-11-13

• Details und Bewertungskriterien

• Lasst das Dokument auch euren AGs zukommen und holt Feedback ein

  • (Tipsy bekommt noch einen Bestätigungslink für die AGs)

• Finale Abgabe: 2026-11-27

Nachfolgend: Bewertungsübersicht & Meilensteine

Fragen so weit?

Punkteverteilung

• AGs

  • ~25p Projekterfolg

  • ~25p Mitarbeit

• Begleitveranstaltung

  • 10p Abschlussvortrag

  • 40p Projektdokumentation

AGs

Details zur Benotung durch AGs (nicht final)

Anforderungen

(siehe auch D03 Anforderungen)

Anforderungen

• „Vertrag zwischen AG und Gruppe“

• Werden vom Team erstellt, vom AG abgenommen

  • Das ganze Team sammelt Anforderungen

• Basieren auf Input vom AG, von eventuellen Nutzer:innen oder eigeninitiativ

• Kleinteilig genug, damit mehrere pro Iteration bearbeitet werden können

• Mehrwert für die Projektziele

• Achtet auch auf nicht-funktionale Anforderungen!

  • Sicherheitsstandards

  • Laufzeitumgebung

Beispiel

Anforderung 101: Nutzersymbole

• Akzeptanzkriterium: Die Spielfiguren werden auf der UI mit farblich unterscheidbaren Symbolen dargestellt.

• Priorität: mittel

• Geschätzter Aufwand: 3 Punkte.

• Tatsächlicher Zeitaufwand: (noch offen)

Beispiel: komplexere Anforderung

Anforderung 117: Spiel speichern und fortsetzen

• Beschreibung: Als Spieler:in möchte ich ein laufendes Spiel speichern, um es später fortzusetzen.

• Akzeptanzkriterien:

  • Im Spielmenü gibt es „Speichern“; danach erscheint das Spiel in der Liste „Gespeicherte Spiele“.

  • Nach dem Laden sind Spielfeld, Punktestand und Charakter identisch zum Zeitpunkt des Speicherns.

  • Gespeicherte Spiele bleiben nach Neustart des Servers erhalten.

• Priorität: hoch

• Geschätzter Aufwand: 21 Punkte (evtl. aufteilen?)

• Tatsächlicher Zeitaufwand: (noch offen)

Beispiel: nicht-funktionale Anforderung

Anforderung 123: Antwortzeit

• Beschreibung: Das Spiel soll sich auch mit vielen Spieler:innen flüssig anfühlen.

• Akzeptanzkriterium: Bei 8 gleichzeitigen Spieler:innen wird ein Spielzug auf allen Clients innerhalb von 200 ms angezeigt (gemessen im Uni-WLAN).

• Priorität: niedrig

• Geschätzter Aufwand: 8 Punkte.

• Tatsächlicher Zeitaufwand: (noch offen)

Anforderungsmanagement

• Anforderungen müssen dokumentiert sein

  • User Stories

  • Issues

  • Tasks

  • Cards

  • Prototypen/Mockups

• Nutzt Formate, die für euch funktionieren!

Struktur von Anforderungen

• Unbearbeitet:

  • Beschreibung

  • prüfbare Akzeptanzkriterien

  • Priorität

  • Aufwandsschätzung

• Erledigt:

  • in Iteration X

  • Aufwand in Stunden

  • Von AG abgenommen

Story Points

• Abstrakte Aufwandsschätzung

• Punkte:

  • 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, $\infty$, ☕, ?

• Relativ zu anderen Anforderungen

• Pointing Poker: https://www.pointingpoker.com/

  • Jeder schätzt für sich

  • Dann wird Konsens gebildet

  • Diskutiert abweichende Meinungen

Velocity

• Im Nachhinein

• Wie viele Story Points pro Iteration?

Beispiel: Burndown-Chart mit Planung und Velocity

Nachfolgend: Begleitveranstaltung und Qualitätssicherung

Fragen?

Begleitveranstaltung

• Meilensteine

• Projektdokumentation

• Abschlussvortrag

Meilensteine

(siehe L02 Meilensteine)

Übersicht Meilensteine

• Projektdatenverwaltung

• Lauffähiger Code

• Pair Programming

• Code Review Checkliste

• Automatisierte Tests (oder Testcheckliste)

• Vollständiger Arbeitsablauf (bis 2027-01-27)

Meilensteine

• Im Projekttagebuch im Tipsy eintragen

• Teambegleitung prüft

  • Zugriff auf Repositories, Dokumente und Tools sicherstellen

  • Kleine Mängel sind ok – fehlende Prozesse nicht

• Verpasst? In der Projektdokumentation begründen

Meilenstein: Projektdatenverwaltung

• 2026-11-11 (Details)

• Gemeinsamer Kommunikationskanal und Kalender

• Git-Repository auf einer Forge, Ort für Anforderungen

• Fester Ort für Dokumente, Protokolle, Timetracking

• Zugriff für Team, TB (und AG)

• Protokolle der bisherigen Meetings abgelegt

• Kurzbeschreibung: Welche Tools wofür, wo findet die TB was?

Zeiterfassung: Kategorien mitschreiben

• Alle Zeiten erfassen, auch bisherige, mit Kategorie

• Daraus entsteht der Pie-Chart für die L03 Projektdokumentation

Meilenstein: Lauffähiger Code

• 2026-11-18 (Details)

• Erste lauffähige Version in der Zielumgebung

  • kann extrem minimal sein

• Code liegt im Repository

• README: Wie baut und startet man es?

• Kurzbeschreibung: Was läuft, wo steht wie man es baut?

Qualitätssicherung

(siehe auch D04 Qualitätssicherung)

QS im WiSe 2026

• Vorgegeben:

  • Pair Programming

  • Code Reviews

  • Tests

• Systematisch, durchführbar, überprüfbar

• Zusätzliche Wünsche der AGs: siehe Qualitätssicherungsziele

Vergleiche auch Software Engineering Best Practices von Sven Amann

Pair & Group Programming

• Dient der Wissensweitergabe

• Konzept: Arbeiten mit kurzen Kommunikationswegen

• Arbeitet gemeinsam im gleichen Raum (auch virtuell!)

• Klassisch: Eine steuert, beide denken

• Auch möglich:

  • Alle arbeiten an verschiedenen Dingen.

  • Bei aufkommenden Fragen werden dynamisch Gruppen gebildet.

  • Group Programming: das ganze Team an einer Aufgabe

• Gezielt bei komplexeren Problemen einsetzen

• Beginnt mit Pair Programming, um ins Projekt zu finden.

Meilenstein: Pair Programming

• 2026-11-25 (Details)

• Jede:r hat mindestens eine Session Pair oder Group Programming gemacht

  • Woran habt ihr gearbeitet? In welcher Form?

• Danach bewertet: Hat es sich gelohnt?

• Kurzbeschreibung: Woran, in welcher Form, und wie geht es weiter?

Code Reviews

• Reviewer:in hat Code nicht geschrieben

• Alle Teammitglieder reviewen (abwechselnd)

• Systematische Reviews

  • Wann? (z.B. vor Akzeptanz)

  • Checkliste

• Verteilt Wissen im Team

• Code-Analyse-Tools helfen

Sobald ihr Routine habt: Jeder Code wird gereviewt

Meilenstein: Code Review Checkliste

• 2026-12-02 (Details)

• Schriftliche Checkliste mit Prüfkriterien

• Festgelegt, wann Reviews stattfinden

• Erste Reviews nachvollziehbar (z.B. Merge Requests mit Kommentaren)

• Kurzbeschreibung: Wo liegt die Checkliste, wann reviewt ihr, wo sieht die TB Beispiele?

Tests

• Manuell

  • Checklisten!

  • Prüfbarkeit!

• Automatisch

  • Unit-Tests, Integrationstests

  • Continuous Integration

• Wie ist der Prozess bei Testfehlern?

• Tests decken im Großen und Ganzen alle Funktionen ab

• Startet so früh wie möglich mit Tests

  • Etwas ist besser als nichts

  • Bleibt flexibel

Meilenstein: Tests

• 2026-12-16 (Details)

• Automatisierte Tests, idealerweise per CI

• Sonst: Testcheckliste, regelmäßig abgearbeitet und protokolliert

• Festgelegt, wann und wer testet

• Kurzbeschreibung: Was wird wie getestet, wo sieht die TB Tests/Testprotokolle?

Meilenstein: Vollständiger Arbeitsablauf

• 2027-01-27 (Details)

• Alles Bisherige läuft zusammen über komplette Iterationen

• Projektabschluss mit AG besprochen

• Kurzbeschreibung: Typische Iteration? Abschluss gefährdet?

Nachfolgend: Bewertung

Fragen?

Abgaben

• Projektdokumentation

  • ~7 Seiten Abschlussbericht

  • Enthält alles Besprochene + Reflexion

• Abschlussvortrag

  • ganzes Team

  • 6 Minuten Vortrag + 6 Minuten Fragen

Wie fällt man durch?

• Keine Abgabe (oder absurd, oder offensichtlich KI-generiert)

  • Spezifikationsdokument, Projektdokumentation, Abschlussvortrag

• Teambegleitungen haben keine Indizien auf:

  • Projektmanagement

  • Anforderungen

  • Tests

  • Code Reviews

  • Pair Programming

• Mehr als 4 Wochen unerwartet nicht erreichbar

Wie bekommt man eine

sehr gute Note?

• Spezifikationsdokument: enthält alle Punkte

• Meilensteine erreicht: Teambegleitung bestätigt Sinnhaftigkeit

  • Verpasste Meilensteine sind begründet

• Abschlussvortrag: verkauft euren Prozess gut

• Projektdokumentation: eigene Gedanken zu sinnvollem Prozess

Nächste Vorlesung Januar! 2027-01-13

Nächste Woche:

• Spezifikationsdokument

• Meilensteine im Projekttagebuch

Fragen?